One of the characteristics of Next Generation Network (NGN) is that the service layer is separated from the transport layer, and the transport layer is usually implemented based on packet switching technology and optical technology. At present, the TISPAN workgroup of Europe Telecom Standard Institute (ETSI) has established a functional framework of NGN, that supports Fixed-Mobile Convergence, on the basis of Third Generation IP Multimedia Subsystem (3G IMS). As shown in FIG. 1, the framework includes a service layer and an IP (Internet Protocol)-based transport layer.
As shown in FIG. 1, the service layer is composed of Network Attachment Subsystem (NASS), Resource and Admission Control Subsystem (RACS), IP Multimedia Subsystem (IMS), PSTN/ISDN Emulation Subsystem (PES), other multimedia subsystems and applications, and common service components of those subsystems; the common service components include application servers, charging functions, user profile management, and security control, etc.
Under the control of NASS and RACS, the transport layer provides IP connections between NGN terminals, which hides the transport techniques used in access and core networks below IP layer. Those subsystems can be distributed in the administrative domains of network/service providers.
In an NGN environment, a critical component that provides support for end-to-end QoS control is RACS. The position of RACS in the overall framework of NGN and the interface relationship between the RACS and the external entities are shown in FIG. 2. The RACS needs to have interfaces with the transport layer, customer premise equipments (CPEs), NASS, IMS, PES, other service subsystems, and RACSs in other networks. RACS provides admission control function; the admission control includes resource availability check based on the user profiles stored in NASS. Resource availability check means the admission control verifies whether the requested bandwidth is consistent with the subscribed bandwidth and the used bandwidth of each user.
Due to diversity and multimedia feature of NGN services, how to implement QoS control on user service on the basis of IP-based transport layer has become an important task in NGN technical research. To this end, Internet Engineering Task Force (IETF) has put forward Integrated Service/Resource Reservation Protocol (IntServ/RSVP), Differentiated Service (DiffServ), and their policy control models and mechanisms.
In IntServ/RSVP and its policy control model put forward by IETF and the Next Step IP Signaling (NSIS) draft that is being established, as shown in FIG. 3, users can transfer QoS parameters to the network through dedicated resource reservation signaling, to request for an expected QoS assurance level. Due to the fact that both RSVP and NSIS operate on the transport layer and pass through the same route and path as the data flow does, it is required that the CPEs support either RSVP or NSIS protocol, so as to send explicit QoS requests to the network. Such a QoS assurance method is inapplicable for users who can not initiate explicit QoS requests to the network.
In actual applications, i.e., in the current network environments, most of the CPEs (i.e., users) do not support RSVP/NSIS protocol. In addition, even if new user terminals will support RSVP/NSIS protocol gradually, it is required to provide QoS requirements that can meet the users' traffic flow on the network side. However, the Policy Decision Function (PDF) performs admission control and gate control only based on user profile and the operator's management policy rules without checking the availability of network resources based on resource status; and, consequently, assured QoS can not be provided in accordance with the actual conditions of the network.
IETF has also put forward DiffServ and its policy control model, as shown in FIG. 4. In detail, the user makes requests and negotiations with the network on QoS, by using either of the following two methods:
One method is: CPEs perform traffic classification, Diffserv marking, policing, and shaping for the user packets; the network equipment trusts the DiffServ marks in the user packets and performs Diffserv forwarding.
The other method is: users subscribe Service Level Agreement (SLA) with the network operator through an administrative approach; the SLA contains the required QoS parameters (e.g., bandwidth and DiffServ type) for user traffic. Network Management System (NMS) statically configures the QoS parameters requested by users onto edge devices of the network via policy control interface or network management interface. The edge devices perform traffic classification, Diffserv marking, policing, and shaping on the user packets in accordance with the QoS configuration; the core devices perform DiffServ forwarding in accordance with the DiffServ marks in the packets marked by the edge devices.
In DiffServ and its policy control model put forward by IETF, users perform QoS negotiation with the network in the management plane. In the network, the user QoS request is represented with the value of the Diffserv mark in the packet. Since a DiffServ mark has a length of only 3 bits, which can only reflect the relative requirements including QoS level and priority but can not transfer the user expected QoS parameters from end to end, including bandwidth, delay, jitter, and packet loss rate, etc.; therefore, the user traffic can only be provided with a relative QoS differentiation from the network. In addition, it is unable to implement QoS assurance for user service based on network resource availability as well.